1. Technical Field
The present invention relates in general to virtual switches and, in particular to, techniques for operating virtual switches in a virtualized computing environment.
2. Description of the Related Art
The term ‘utility computing’ has been used to refer to a computational model in which processing, storage and network resources, software, and data are accessible to client computer systems and other client devices (e.g., mobile phones or media players) on demand, much like familiar residential utility services, such as water and electricity. In some implementations, the specific computational resources (e.g., servers, storage drives, etc.) allocated for access and use by client devices are specified by service agreements between the utility computing provider and its customers. In other implementations, commonly referred to as “cloud computing,” details of the underlying information technology (IT) infrastructure are transparent to the utility computing customers.
Cloud computing is facilitated by ease-of-access to remote computing websites (e.g., via the Internet or a private corporate network) and frequently takes the form of web-based resources, tools, or applications that a cloud consumer can access and use through a web browser, as if the resources, tools, or applications were a local program installed on a computer system of the cloud consumer. Commercial cloud implementations are generally expected to meet quality of service (QoS) requirements of cloud consumers, which may be specified in service level agreements (SLAs). In a typical cloud implementation, cloud consumers consume computational resources as a service and pay only for the resources used.
Adoption of utility computing has been facilitated by the widespread utilization of virtualization, which is the creation of virtual (rather than actual) versions of computing resources, e.g., an operating system, a server, a storage device, network resources, etc. For example, a virtual machine (VM), also referred to as a logical partition (LPAR), is a software implementation of a physical machine (e.g., a computer system) that executes instructions like a physical machine. VMs can be categorized as system VMs or process VMs. A system VM provides a complete system platform that supports the execution of a complete operating system (OS), such as Windows, Linux, AIX, Android, etc., as well as its associated applications. A process VM, on the other hand, is usually designed to run a single program and support a single process. In either case, any application software running on the VM is limited to the resources and abstractions provided by that VM. Consequently, the actual resources provided by a common IT infrastructure can be efficiently managed and utilized through the deployment of multiple VMs, possibly associated with multiple different utility computing customers.
The virtualization of actual IT resources and management of VMs is typically provided by software referred to as a VM monitor (VMM) or hypervisor. In various implementations, a VMM may run on bare hardware (Type 1 or native VMM) or on top of an operating system (Type 2 or hosted VMM).
In a typical virtualized computing environment, VMs can communicate with each other and with physical entities in the IT infrastructure of the utility computing environment utilizing conventional networking protocols. As is known in the art, conventional networking protocols are commonly premised on the well known seven layer Open Systems Interconnection (OSI) model, which includes (in ascending order) physical, data link, network, transport, session, presentation, and application layers. VMs are enabled to communicate with other network entities as if the VMs were physical network elements through the substitution of a virtual network connection for the conventional physical layer connection.
Traditionally, virtual switches (vswitches) have been implemented (in software) within a VMM to provide connectivity between VMs controlled by the VMM and between the VMs and an external network. Traditional vswitches (or virtual Ethernet bridges (VEBs)) have performed all network traffic forwarding within an associated server completely in software or using software in combination with one or more network interface controllers (NICs). For example, in order to transfer information between VMs controlled by a same VMM, a VEB has performed a memory copy operation to transfer packets between VMs.
Recently, a newer class of vswitch, known as a virtual Ethernet port aggregator (VEPA), has been proposed. In general, vswitches implementing VEPAs do not perform local forwarding for traffic emanating from a VM completely in software. That is, in vswitches implementing VEPAs, all packets (including intra-VMM VM-to-VM packets) are transmitted on a link to a physical network switch. In the VEPA implementation, the physical network switch performs additional processing on the packets and transmits the packets back on the same link, when a destination VM is controlled by a same VMM as a source VM. In general, transmitting a packet back on a same physical switch port on which the packet was received has required a physical network switch to implement a feature known as ‘reflective relay’ on the port.